How to Map Your Hierarchy in Rules

Rules are entered in the Activities settings on the Rules page in tabular form. Each line defines one relationship:

Lines in which neither a parent group nor a parent type is entered define the root elements. In the following example, the Plan group is created without a parent. This means that all activityClosed Any targeted action or measure taken by a company to promote its products or services, attract customers, or increase sales. types assigned to the Plan group can be set as root element:

Let's assume you want to create a relationship between the Group 1 and its child Group 2.

The following screenshot shows this case in the second line. This means that all activity types of the CampaignClosed A coordinated series of marketing activities aimed at achieving a specific marketing goal. group can be created as children of all activity types of the Plan group.

However, you may find that an activity typeClosed A template for activities that defines what attributes are available and required, and what workflows are associated with the activity. should only be used as a child of a specific other activity type. An example could be that you want to use certain campaign types only within a strategically oriented plan. The following picture shows Activity Type K (assigned to the Group 1), for which only Activity Types D and H should be created as children:

You create this as follows:

If you want to maintain the exclusive relationship of Activity Type K to D and H, you must create separate rules for B and E as well. A simple solution is to also only link these to activity types from the Campaign group, for example Activity type E as parent of Activity type J and Activity type B as parent of Activity type C:

The previous sections describe rules that connect two levels of the hierarchyClosed The organizational structure of folders, sub-folders and investment plans in Spend. either only via groups or only via types. But what if your hierarchy is more complex? This section provides solutions for various cases.

The most important rule to consider is: Each activity type and activity type groupClosed A collection of related activity types, used to organize and manage activity types more efficiently. can only have one parent.

Let's start with the following example, where Activity Type K is defined as parent for Activity Types D and H.

In addition to the combination of types described in the previous section, the following cases are also conceivable:

  • Activity type E as parent of Activity type C and Activity type J, i.e. activities of type C and J can be created as children of activities of type K.

  • Activity type B as parent of Campaign group, i.e. all activities of types D, C, H and J can be created as children of activities of type B.

This mapping is possible because it does not violate the restriction that each object may only have one parent and can be implemented by rules as follows:

But how do you handle this if you have to create several rules for Group 2 as child? An example would be if in the previous example Activity Type E was also a possible parent of Group 2. Well, in this case, split up your hierarchy:

This reduces your set of rules to 4 simple group rules:

  • One each for Group 1A and Group 1B as root element

  • One each for the relationship from Group 1A to Group 2A and from Group 1B to Group 2B